Skip to content

fix(recording): disable Vulkan on Wayland so PipeWire capture can import DMA-BUF frames#91

Merged
EtienneLescot merged 1 commit into
mainfrom
claude/fix-wayland-vulkan-capture
Jul 16, 2026
Merged

fix(recording): disable Vulkan on Wayland so PipeWire capture can import DMA-BUF frames#91
EtienneLescot merged 1 commit into
mainfrom
claude/fix-wayland-vulkan-capture

Conversation

@EtienneLescot

@EtienneLescot EtienneLescot commented Jul 16, 2026

Copy link
Copy Markdown
Collaborator

Closes #92.
Closes #93.

Problem

A tester on v1.7.0-rc.1 (Wayland, Intel iGPU) reported screen recording not working, with these logs:

'--ozone-platform=wayland' is not compatible with Vulkan.
Consider switching to '--ozone-platform=x11' or disabling Vulkan
Failed to record frame: Error creating EGLImage - EGL_BAD_MATCH
DMA-BUF modifier 72057594037927944 failed for format 12 (Spa:Enum:VideoFormat:BGRA),
marking as failed and renegotiating stream parameters

In electron/main.ts we force ozone-platform=wayland and enable WebRTCPipeWireCapturer, but leave Vulkan enabled. Chromium's Wayland Ozone backend can't use Vulkan; when it initializes Vulkan, the PipeWire desktop-capture frames fail to import into EGL (EGL_BAD_MATCH), the stream renegotiates, and recording produces no usable frames. Chromium prints the fix itself in the first log line.

Fix

Append disable-features=Vulkan on Wayland so capture uses the GL/EGL path, which is what the DMA-BUF import expects.

app.commandLine.appendSwitch("disable-features", "Vulkan");

Validation needed — cannot reproduce in CI

CI runs on Linux headless with no Wayland session, and maintainers here are on macOS/Windows, so this can't be verified automatically. It needs a real Wayland box.

@reporter — could you build this branch and confirm recording works?

git fetch origin claude/fix-wayland-vulkan-capture
git checkout claude/fix-wayland-vulkan-capture
npm ci && npm run dev

Then start a screen recording and check the logs no longer show EGL_BAD_MATCH / DMA-BUF renegotiation, and the output has real frames.

Also, to help triage the rest

The shared logs evidence this one capture defect (two symptoms). The report mentioned 4 bugs total — could you list the other three, each with a short repro + its own log slice? And to confirm scope for this one:

  • Compositor: GNOME / KDE / Sway / other?
  • Mesa version (glxinfo | grep "OpenGL version" or eglinfo)?
  • Confirm GPU is Intel (the failing DMA-BUF modifier decodes to an Intel tiled modifier)?

If EGL_BAD_MATCH persists even with Vulkan disabled, the next levers are pinning the GL backend (--use-gl=egl / ANGLE) or forcing linear buffers — but let's confirm this narrower fix first.

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Bug Fixes
    • Improved application compatibility and stability when running on Linux systems using Wayland.
    • Disabled Vulkan usage in Wayland sessions to help prevent graphics-related issues.

Validated by the reporter on a real Wayland + Intel setup: capture works and runs at 60 fps in and out. This confirms the fps drop (#93) was downstream of the DMA-BUF import failure, not an encoder bug. Cursor issues (#94) are unaffected and tracked separately.

…ort DMA-BUF frames

On Wayland the app forces ozone-platform=wayland and enables the WebRTC
PipeWire capturer, but leaves Vulkan enabled. Chromium's Wayland Ozone
backend can't use Vulkan, so when it initializes Vulkan the desktop-capture
DMA-BUF frames fail to import into EGL:

  '--ozone-platform=wayland' is not compatible with Vulkan
  Error creating EGLImage - EGL_BAD_MATCH
  DMA-BUF modifier ... failed for format 12 (BGRA), marking as failed and renegotiating

The stream then renegotiates and screen recording produces no usable frames.
Append disable-features=Vulkan on Wayland so capture uses the GL/EGL path,
which is what the DMA-BUF import expects. This is the fix Chromium itself
suggests in the log.

Reported on v1.7.0-rc.1 (Intel iGPU + Wayland). Needs validation on the
reporter's setup.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Jul 16, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Walkthrough

The Electron main process now disables Chromium’s Vulkan feature when running in a Linux Wayland session, alongside the existing Wayland-specific command-line switches.

Changes

Wayland Vulkan Configuration

Layer / File(s) Summary
Disable Vulkan for Wayland capture
electron/main.ts
The Linux Wayland detection path documents the Vulkan/DMABUF/EGL incompatibility and adds Chromium’s disable-features=Vulkan switch.

Estimated code review effort: 1 (Trivial) | ~3 minutes

Suggested reviewers: siddharthvaddem

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Description check ⚠️ Warning The description explains the problem and fix, but it misses most template sections such as Summary, Type of change, Release impact, and Desktop impact. Add the missing template sections and fill in Type of change, Release impact, Desktop impact, Screenshots/video, and a concise Summary/Testing section.
✅ Passed checks (4 passed)
Check name Status Explanation
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Title check ✅ Passed The title clearly and concisely describes the main change: disabling Vulkan on Wayland to fix PipeWire capture.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch claude/fix-wayland-vulkan-capture

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant